T3インスタンスの性能をWordPress環境で確認してみた

はじめに

AWSチームのすずきです。

東京リージョンで利用可能となった「T3」インスタンス。 Wordpress(PHP7)の実行環境として導入し、「T2」インスタンスと比較する機会がありましたので、 紹介させていただきます。

【速報】T3インスタンスがリリースされました！

環境

• リージョン: AWS東京リージョン
• アベイラビリティーゾーン: ap-northeast-1a
• OS: AmazonLinux 2018.03
  • Linux version 4.14.62-65.117.amzn1.x86_64
  • AMI: aws-elasticbeanstalk-amzn-2018.03.0.x86_64-php70-hvm-201808172110 (ami-07202bf6c4a45e244)

構成図

t3.small 2台、t2.small 2台、4台のEC2インスタンスを用意し、同一ELB配下にアタッチ。Cloudwatchのメトリックを利用した比較を行いました。

結果

Cloudwatch(EC2)

ネットワーク(イン/アウト)

4台のEC2、ELBにより均等な負荷分散がされている事を確認できました。

CPU使用率

• 「t3.small」のCPU使用率、「t2.small」と比較し半減した事を確認できました。
• 「t3.small」のvCPUは2、「t2.small」の1から増加した効果と推測されます。

CPUクレジット使用状況

• 「t3.small」のCPUクレジット消費、「t2.small」と比較し2〜3割程度少ない事が確認出来ました。
• 「T3」はCPUコア性能が反映されていると推測されます。

CPUクレジット残高

• 1時間あたり多くのCPUクレジットを受け取る「t3.small」、起動後数時間で初期クレジット(30)を受け取る「t2.small」を上回る事が確認できました。

パフォーマンスインサイト(Aurora)

今回利用したDBはパフォーマンスインサイトを有効化したAuroraでしたので、DB負荷の変化を確認してみました。

「T3」は「T2」より若干ですがDBの専有時間(SAA)が短縮していた事が確認できました。

「T3」と「T2」の差異があった項目は「io/socket/sql/client_connection」。

「T3」で利用出来るようになった最大5 Gigabitまでバーストするネットワーク性能と、NITRO世代の仮想化に伴うオーバーヘッドの改善効果が現れていると思われます。

コスト比較

「T3」は同等スペックの「T2」と比較し10%安いオンデマンド料金が設定されています。

1時間あたりに受け取るCPUクレジットが増量されていた「t3.nano」「t3.micro」「t3.small」 は、 多くのバーストするCPU性能をコストパフォーマンスよく利用できる事が期待出来ます。

インスタンスタイプ	1 時間あたりに受け取る CPU クレジット	1時間料金(USD)	1CPUクレジット費用(USD)
t3.nano	6	0.0068	0.0011
t3.micro	12	0.0136	0.0011
t3.small	24	0.0272	0.0011
t3.medium	24	0.0544	0.0023
t3.large	36	0.1088	0.0030
t3.xlarge	96	0.2176	0.0023
t3.2xlarge	192	0.4352	0.0023
t2.nano	3	0.0076	0.0025
t2.micro	6	0.0152	0.0025
t2.small	12	0.0304	0.0025
t2.medium	24	0.0608	0.0025
t2.large	36	0.1216	0.0034
t2.xlarge	54	0.2432	0.0045
t2.2xlarge	81.6	0.4864	0.0060

• 1時間料金は、東京リージョンの Linux/UNIX 1時間料金

まとめ

今回の比較に利用したアプリケーション環境(PHP7)では、「t3.small」の採用により、コストパフォーマンスの改善が期待できる結果が得られました。

長時間連続した負荷がかからないWebサーバや、開発環境などでは「T3」のバースト性能がより効果的に利用できると思われます。 NITRO世代に対応したマシンイメージ(AMI)が利用できる場合には是非お試しください。